- Darken --sp-muted-foreground from 46% to 38% lightness (4.31:1 -> ~6.4:1)
- Replace sp-text-emerald-600 with sp-text-emerald-700 in API Credentials
  (3.76:1 -> 5.27:1 on white, 3.57:1 -> ~5:1 on emerald-50)

Resolves 3 axe-core color-contrast violations across all 5 settings tabs.
Verified: 0 contrast issues remain inside #saferpay-settings-root.

Radix Label component does not auto-wire to SelectTrigger; without
an explicit aria-label, screen readers announced only the selected
value. Resolves last open finding in TC-346.1.

Previously Tab could escape the modal into background page content
violating WCAG 2.1.2 (Focus Order) for modal dialogs. Tab/Shift+Tab
now cycle within the modal's focusable elements.

Resolves TC-346.7.

PrestaShop core .btn-primary teal (#25b9d7) on white was 2.6:1 — fails
WCAG 2.1 AA (requires 4.5:1). Scoped override on #saferpay-admin-form
only, so other admin pages keep their PS theme. Refund/Capture buttons
now use the module brand teal #1c7c80 (5.27:1).

Without scope, screen readers cannot reliably associate header cells
with their data column. Resolves TC-346.10 (FO saved credit cards).

The PS Classic theme rendered the Remove link in teal #24b9d7 on white
(2.6:1) which fails WCAG 2.1 AA. Use brand teal #1c7c80 (5.27:1) via
inline color so the override does not bleed to other theme buttons.

The .btn-primary (BO admin order) and .btn-default (FO saved cards)
contrast issues originate in PrestaShop core/theme CSS, not in our
module. Overriding them at module level was the wrong layer:
- fragile against theme updates
- could clash with merchant theme customizations
- inconsistent with our decision to scope SL-346 to module-owned UI

These now match the same out-of-scope category as the BO breadcrumb,
help button, and submenu tabs. Module-owned a11y fixes (React Settings
app contrast, aria-labels, scope=col, focus trap, etc.) remain in PR.

- Disable Save Changes button when username/password empty, credential
  check is in flight, or inline credential error is shown
- Mark JSON API Username and Password as required (visual asterisk +
  aria-required) to surface the requirement before user clicks Save

The Saferpay Fields section was driven by a single hasBusinessLicense
flag derived from the active environment's stored license at page load.
Switching environments client-side did not re-evaluate it, so the
section stayed visible after switching to an environment with no
validated business license.

Expose testHasBusinessLicense and liveHasBusinessLicense separately
from the controller (initial payload and save response), and pick the
active one in api-credentials.tsx based on testMode.

…ntials

Disable Save Changes when API credentials empty or invalid

…nse-visibility

Fix Saferpay Fields visibility per active environment license

The polling script in saferpay_wait.tpl navigated the iframe itself via
window.location.href, leaving the parent window stuck on the SaferPay
iframe controller URL while the cart or order-confirmation page rendered
nested inside the iframe.

Use window.top so the redirect targets the parent window and the user
lands at /cart or /order-confirmation with the proper top-level chrome.

Address review feedback on PR #325:
- Use location.replace() so the polling page is not stored in history
  (Back from order-confirmation should not return to the spinner).
- Wrap window.top access in try/catch with an in-iframe fallback in
  case sandboxing or browser policy blocks the breakout.

…owns show All instead of 0

…rictions-default

BUGFIX: payment methods default to all countries/currencies and dropdowns show All instead of 0

fix: break out of SaferPay iframe on payment status redirect

…rpay transaction abort

… requirement

…redirect-secure-key

BUGFIX: redirect customer to cart instead of order history after Saferpay transaction abort

…le-info

BUGFIX: clarify Hosted field style info banner to mention Custom form requirement

Frontend (api-credentials.tsx): show inline error and disable Save when
any comma-separated entry fails an email regex.

Backend (AdminSaferPayOfficialSettingsController): reject save when
testMerchantEmails or liveMerchantEmails contains a value that fails
Validate::isEmail() — guards against curl/devtools bypass.

BUGFIX: validate Merchant Emails field on save

When 'Behavior when 3D Secure Payer Authentication was not successful'
was set to Authorize, the order was still being captured because the
AUTHORIZE branch was missing and the CANCEL branch did not return early,
so control fell through to the default-payment-behavior Capture block.

Each 3DS-fail branch now returns/dies explicitly, so the configured
3DS-fail behavior is always honored.

isValidResponse() already logs API errors before throwing
SaferPayApiException, so the surrounding catch in get(),
getWithCredentials(), and postWithCredentials() produced a redundant
error row for every failed call. Guard the catch-block logger->error
with if ($response === null) so it only fires on transport-level
failures, where isValidResponse() never ran.